Software of the Month Club 1996 May

home *** CD-ROM | disk | FTP | other *** search

/ Software of the Month Club 1996 May / Software of the Month Club 1996 May.iso / mac / ISO9660 / ZIPFILES / GIM_313.ZIP / GIM11H.DOC < prev next >

Wrap

Text File | 1993-09-09 | 15.6 KB | 348 lines

CHAPTER 11 LISTS OF SIMILAR PERSONS, FAMILIES AND NOTES OR SEARCHING YOUR FOLDER FOR SPECIFIC INFORMATION PART H: ADVANCED EXAMPLES; ARCANE WHERE COMMAND SYNTAX... WARNING!!! This section is NOT FOR THE FAINT OF HEART!!! This section covers advanced topics in GIM LISTS WHERE command construction, and should only be attempted by those persons who feel very, very comfortable with the basics. Before reading this section, you should be very familiar with the sections of this chapter up to this point, and you should have played around with the examples in this chapter and used GIM LISTS on your own folder before continuing. That having been said, turn back now, or read the rest of this section at your own risk! PURPOSE... WHAT THIS SECTION WILL DO FOR YOU As we've said elsewhere, GIM LISTS was designed to be a very powerful database querying mechanism. It was designed, in short, to allow you to search for anything you can imagine. The GIM LISTS tools introduced up to this point are able to handle 95% of the things you may want to look for. However, there are some things that you may want to look for which simply can't be done with the basic GIM LISTS commands. Therefore, the extensions to GIM LISTS described in this section were added to augment the power of GIM LISTS, and to handle those few cases where the basic tools don't suffice. These extensions are referred to tongue-in-cheek as "arcane" commands, because they won't be needed all that often, and because their syntax (admittedly) isn't very intuitive. But they are useful to know about, because they greatly increase your power in those occasional situations where you need to search for something unusual. OVERVIEW... AN OVERVIEW OF THE REST OF THIS SECTION The rest of this section will cover the following situations, which the basic tools can't handle without some help. Along the way, we'll discuss the problems and solutions for each of these situations: 1. You want to create a list persons who have a place name in "Niger", but not "Nigeria", or "Mexico" but not "New Mexico". Or you want to create a list of persons who have a note about "Italy" but not one about "Rome". Or you want to create a list of families with at least one child named David who was born in Wisconsin. 2. You want to create a list of persons who lived at least 80 years. Or who were married to each other for at least 10 years before one of them died. Or who were baptized before the age of eight. 3. You want to create a list of persons whose LDS temple ordinances were performed in temples which didn't exist at the time -- such as a Salt Lake Temple sealing in 1877, or a Nauvoo Temple endowment in 1946, or an Endowment House sealing in 1906. CASE ONE: THE COLON OPERATOR Suppose you want to create a list of persons who have a place name -- any place name -- in "Niger", but not "Nigeria", or in "Mexico" but not "New Mexico". You already know how to search for any place name in Niger. That's done like this: WHERE any place name contains "Niger" But that doesn't rule out place names in "Nigeria", and if you want to leave them out, you're out of luck -- you'll get them anyway. Your first instinct might be to do this, and you'd be wrong: WHERE any place contains "Niger" and any place doesn't contain "Nigeria" This would select people from Niger, but it wouldn't keep out people from Nigeria. If you have someone who is born in Nigeria and who died in Arizona, he or she would be selected, because he or she has a place name that contains "Niger", and another one (Arizona) that doesn't contain "Nigeria". Part of the reason for the confusion is that the following WOULD work: WHERE birth place contains "Niger" and birth place doesn't contain "Nigeria" This looks similar to the problem WHERE command above, which doesn't work. However, this one DOES work, as long as you're only interested in a specific place for each person, such as a birth place. The problem here is that once you include the ANY and ALL modifiers, you open yourself up for ambiguity. The solution to this problem is to introduce the Colon operator (:), and to use it like this: WHERE any place : contains "Niger" and doesn't contain "Nigeria" (Note that there must be at least one space before and after the colon itself.) So why does this WHERE command work if the earlier WHERE command doesn't work? Because "any place contains something" refers to a set of things, and "any place doesn't contain another thing" refers to a set of things, and because each of these sets is evaluated separately. But when we pull the "any place" out in front of a colon operator (:), we evaluate everything after the colon at the same time for each place. That way, someone who was born in Nigeria wouldn't pass the test, although someone born in Niger would. (Also, someone born in Nigeria who died in Niger would naturally also pass the test.) MORE USES FOR THE COLON OPERATOR Now that you've seen the colon operator, you can imagine what other uses it has. Just as with Niger and Nigeria, you can use it to filter out people from Mexico from those from New Mexico. You have a similar problem when you search through a person's notes. If you look for notes about Italy, but not about Rome, you'll get into trouble with this command: WHERE any note contains "Italy" and any note doesn't contain "Rome" ... for the same reason. If the christening source note contains "Rome, Italy" and the death research note doesn't say anything about Rome, then this person will be selected, even though you didn't want to select him or her. The solution, of course, is this: WHERE any note : contains "Italy" and doesn't contain "Rome" The story is the same if you want to create a list of families with at least one child named David who was born in Wisconsin. (I know; it's a far-fetched example; but then again, that's why these are called "arcane commands"!) This one won't work: WHERE any child given is "David" and any child birth place contains "Wisconsin" ... because it will select any family with a child named David -- whether or not he was born in Wisconsin -- as long as he or some OTHER child WAS born in Wisconsin. The solution is this, which will work: WHERE any child : given is "David" and birth place contains "Wisconsin" The moral of this story is: pay close attention when you want to use the ANY modifier in the same WHERE command with an AND conjunction. That situation is an ideal time to use the Colon operator. CASE TWO: THE PLUS AND MINUS OPERATORS By now, you know how to compare date variables. For example, you know how to search for persons who died before they were born, like this: WHERE death date is before birth date This is an ideal way to search for errors in your folder. I should know; I've used it, and found several typos and other problems in my folder! However, although this gives us the ability to find gross errors in our data, it is much too limited. Suppose you want to persons who died before they were ten years old. How would you do it? The concept is simple: we clearly want to modify the WHERE command above so that it reads something like "WHERE death date is before birth-date- plus-ten-years". So as not to keep you in undue suspense, that concept is translated into WHERE command syntax as follows: WHERE death date is before birth date PLUS 100000 Any date variable can be modified with a PLUS or MINUS keyword in this way. The value after the PLUS or MINUS keyword is of the form YYYYMMDD, where YYYY is a number of years, MM is a number of months, and DD is a number of days. Therefore, 100000 should be interpreted by splitting it up into three parts -- in other words: 10 (years), 00 (months), and 00 (days). MORE USES FOR THE PLUS AND MINUS KEYWORDS Having said that, you should be see how to create a list of persons who lived at least 80 years. The WHERE command would look like this: WHERE death date is after birth date PLUS 800000 It is also straightforward how to create a list of persons who were baptized before the age of eight. That WHERE command would look like this: WHERE baptism date is before birth date PLUS 80000 It is a little less obvious how to create a list of couples who were married to each other for at least 10 years before one of them died. Study the following WHERE command, which is applied to a list of families: WHERE husband death date is after marriage date PLUS 100000 and wife death date is after marriage date PLUS 100000 WARNINGS ABOUT THE PLUS AND MINUS MODIFIERS There are two things to be aware of with regard to these modifiers. WARNING NUMBER ONE: The first is that GIM LISTS is smart enough to ignore date comparisons when dates don't exist. In other words, if you're looking for people born before 1700, GIM LISTS is smart enough to ignore people whose birth dates are missing, and it doesn't report them to you as persons born before 1700. However, all bets are off when you use the PLUS and MINUS modifiers. When you use them, GIM LISTS is unable to distinguish very early dates from missing ones. To get around this problem, you should combine PLUS and MINUS searches with IS COMPLETE or IS ACCEPTABLE operands. So for example, to be absolutely accurate, the test above for couples married at least ten years should really look something like this: WHERE marriage date is complete and husband death date is complete and wife death date is complete and husband death date is after marriage date PLUS 100000 and wife death date is after marriage date PLUS 100000 WARNING NUMBER TWO: When adding years, months, and days to a date with the PLUS and MINUS modifiers, GIM LISTS isn't smart enough to carry excess days and months into the next month and year. It isn't smart enough, in other words, to add six months to December 1805, and get (as you might expect) May, 1806. That's because it was only designed to handle gross changes in time, such as "ten years" or "eighty years". It can still handle the months and days okay, as long as it isn't expected to carry them over. To be brutally, graphically descriptive, what's actually going on is this: GIM LISTS takes the year and translates it into a number. For example, December 23, 1805, becomes 18051223. If you then add 38 years, six months and four days -- which you specify as 380604 -- to this value, GIM LISTS simply adds them, resulting in 18431827. As you can see, the result is "the 27th day of the 18th month of 1843", which really doesn't mean a whole lot, and GIM LISTS will behave in unpredictable ways when it tries to compare this value to a "real" date. The moral of the story is: use months and days at your own risk, realizing that they might work well, and they might not. Your best advice is to stick with comparing years this way. CASE THREE: THE PLACEBEG AND PLACEEND OPERANDS You already have the tools to handle most of the situations that connect dates with places. You can, for example, find persons born in Connecticut before 1700. With the colon operator, you can find any event which took place in a certain place at a certain time. In the case of LDS temples, however, this is a little more problematic. You can still do the same sort of thing, by searching for any LDS event in the Salt Lake Temple before it opened in 1893. But doing so requires that you already know the opening and closing dates for each of the LDS temples. Moreover, it doesn't give you the flexibility of comparing opening and closing dates for each of the temples in a single command. To address this concern, GIM LISTS provides PLACEBEG and PLACEEND operands. These are date operands, and they only have meaning for LDS events -- baptism, endowments, and sealings. They represent the opening and closing dates for each temple, and they work like this: Suppose you want to create a list of persons whose LDS temple ordinances were performed in temples which didn't exist at the time -- such as a Salt Lake Temple sealing in 1877, or a Nauvoo Temple endowment in 1946, or an Endowment House sealing in 1906. Rather than searching for each of these things on a temple- by-temple basis, you can issue a WHERE command like this: WHERE endowment date : is before PLACEBEG or is after PLACEEND You know already that this command tells GIM LISTS to search through each person's endowments. For each of these endow- ments, it compares the date of the endowment to the opening date of the place of that endowment (PLACEBEG), and is also compares the date of the endowment to the closing date of the place of that endowment (PLACEEND). This capability provides a quick way to search your folder for possible typos or other data inconsistencies. Please note: if an LDS baptismal date exists, and if an LDS baptismal place name contains the word "living", it is always true that the baptismal date is between PLACEBEG and PLACEEND.